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(57) ABSTRACT 

A method and computer program operative in an e-mail 
server for reducing unsolicited e-mail in an enterprise com- 
puting environment. According to the invention, e-mail is 
accepted for delivery to e-mail clients only if it is from an 
address that has been verified by an e-mail server and/or 
approved by a recipient. When an e-mail from a particular 
address is received at the e-mail server for the first time, the 
server automatically issues an e-mail to the address to 
request that the sender verify the authenticity of the original 
message. If a return acknowledgement is received within a 
given time period, the e-mail is deemed to be authentic and 
delivered to its intended recipient within the enterprise. Mail 
messages from previously-verified addresses need not be 
rechecked. 

3 Claims, 3 Drawing Sheets 



215 



CODE 
217 



216- 



220- 



222- 



224- 




OfJERMININC 
CODE 



ISSUING 
CODE 



214a 



212o 



HOLDING 
QUEUE 



-214b 



v 218 k 



QUEUE 
CODE 



RELEASE 
C00E 



FLUSH 
CODE 



UPDATE 
CODE 



2l4n 



-226 



LIST OF 
APPROVED 
ADDRESSES 


r-212b 


« 




I 



s 

212n 



03/10/2004, EAST Version: 1.4.1 



U.S. Patent Feb. 10,2004 Sheet 1 of 3 US 6,691,156 Bl 




FIG. 4 



System Admin - Anti-Spamming Options 



EES 



E-Mail Clients 
Name&Domain Tf 



~T 

402 



a 



Holding Queue Time: 
^aA 11 



406- /- ° Ac *d Sending Address To All Lists 
408-^° Acce P* Any Sending Address In Domain 
410^° Deliver Unsolicited At A Lower Priority 



Frequency: | days 



412 



Use Default 



OK 



03/10/2004, EAST Version: 1.4.1 



U.S. Patent Feb. 10,2004 Sheet 2 of 3 



US 6,691,156 Bl 



215 



CODE 

7" 

217 



206- 
206- 



216 



220 



222 



224 



E-MAIL 
CLIENT 



E-MAIL 
CLIENT 




210 



ANTI-SPAMMING 
AGENT 



DETERMINING 
CODE 



ISSUING 
CODE 




HOLDING 
QUEUE 



■218 



QUEUE 
CODE 



214n 



LIST OF 
APPROVED 
ADDRESSES 



212n 



RELEASE 
CODE 



FLUSH 
CODE 



UPDATE 
CODE 



•226 



FIG. 2 



03/10/2004, EAST Version: 1.4.1 



U.S. Patent 



Feb. 10, 2004 Sheet 3 of 3 



US 6,691,156 Bl 



FIG. 3 



FORWARD TO 
E-MAIL CLIENT 

7 

312 



ESTABLISH LIST OF 
APPROVED ADDRESSES 



START ANTI-SPAM AGENT 




SAVE RECIPIENT'S ADDRESS IN THE 
LIST OF APPROVED ADDRESSES 




PLACE E-MAIL IN HOLD QUEUE 



GENERATE NEW E-MAIL 



■300 



-302 



-306 



-314 



■316 



DELETE E-MAIL FROM 
HOLDING QUEUE 



T 

320 




RELEASE E-MAIL FROM 
HOLDING QUEUE 



FORWARD TO E-MAIL CLIENT 



ADD E-MAIL SENDING 
ADDRESS TO LIST 



-322 



324 



-326 



03/10/2004, EAST Version: 1.4.1 



US 6,6! 

1 

METHOD FOR RESTRICTING DELIVERY 
OF UNSOLICITED E-MAIL 

BACKGROUND OF THE INVENTION 

1. Technical Field 

This invention relates generally to information delivery in 
a computer network. More particularly, the invention relates 
to techniques for restricting delivery of unsolicited e-mail, 
commonly known as "spam." 

2. Description of the Related Art 

E-mail has become the communication method of choice 
throughout the business world as well as for the general 
public. In a typical enterprise environment, a mail server 
(such as UNIX SendMail) has a local mail delivery agent or 
client (typically . . . /bin/mail on UNIX systems) that stores 
an incoming c-mail on a local file system and delivers it to 
an end user via POP, IMAP or a command line program. 
Such agents typically provide the basic functionality of 
logging in an e-mail message and copying that message to 
a client machine's mail spool. Internet-based client-server 
messaging systems include, for example, Lotus Notes, 
which provides e-mail, calendaring, group scheduling, Web 
access and information management, integrated in an easy- 
to-use and customizable environment. 

The rapid increase in the number of users of the Internet 
has made e-mail an attractive advertising medium. 
Unfortunately, however, e-mail is now frequently used as the 
medium for widespread marketing broadcasts of messages 
to large number of e-mail addresses. Large service providers 
and corporations are particularly susceptible to this practice, 
which is commonly known as spamming. 

The desire to reduce spam has led to both regulatory and 
technical solutions. Several states have passed legislation 
that ban the practice of sending spam e-mail and impose 
criminal sanctions for violations. A summary of these regu- 
lations is available at the following URL: http:// 
www.sork.com/spamlaws/state/summary.html#ok. Techni- 
cal solutions include a number of techniques. The most 
common one is to filter unsolicited e-mail by blocking 
e-mails from particular e-mail addresses that originate such 
messages. This approach, however, is vulnerable to rapid 
changes in the source of the unsolicited e-mail, which is 
relatively easy because most spam is generated by auto- 
mated means. Such approaches also typically require the set 
up and maintenance of a complex filtering mechanism. 

Some e-mail clients, e.g., Eudora Pro, allow the end user 
to set filters that can be set to scan incoming e-mail and then 
perform a designated function with that e-mail. Such pro- 
grams have been set up to scan for messages that do not 
contain a user's personal e-mail address and to filter such 
messages into a "hold for review" mailbox. By transferring 
messages that are not personally addressed, the system can 
be programmed to attempt to filter out spam. 

Another approach to filtering unsolicited e-mail is 
described in U.S. Pat. No. 5,999,932 to Paul. In this patent, 
a user creates an inclusion list including identification data 
for identifying e-mail desired by the user. Data from one or 
more fields of incoming e-mail are compared with the 
identification data stored in the inclusion list. If no match is 
detected, the system performs at least one heuristic process 
to determine whether the e-mail may be of interest to the 
user. If the e-mail message does not satisfy any heuristic 
criteria, the message may be marked with a display code, 
such as "junk." 
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Yet another approach to the problem of spam is provided 
by products that attach digital signatures to outgoing mail 
and that then monitor incoming mail looking for valid 
signatures. One such product is available commercially as 

5 AutbentiMail™, from Omnipoint Technologies, Inc. This 
system uses an intermediary server between the external 
Internet and an internal mail server. Before an e-mail is 
delivered to the Internet, a signature is attached to the 
message to protect the user's e-mail address. If a third party 

10 server tries to forward the message or compile the sender's 
name in a mailing list, however, the signature is invalidated 
to prevent spamming. 

While the above-described techniques do prevent and/or 
attempt to minimize the harmful effects of spam, they 

15 require complex and costly software and/or servers that are 
difficult to set up and maintain. 

There remains a need for a simple, yet effective way of 
restricting unsolicited e-mail within an enterprise e-mail 
environment. The present invention addresses this need. 

20 

BRIEF SUMMARY OF THE INVENTION 

The present invention is a method and computer program 
operative in an e-mail server for reducing unsolicited e-mail 

25 in an enterprise computing environment. According to the 
invention, e-mail is accepted for delivery to e-mail clients 
only if it is from an address that has been verified by an 
e-mail server and/or approved by a recipient. When an 
e-mail from a particular address is received at the e-mail 

30 server for the first time, the server automatically issues an 
e-mail to the address to request that the sender verify the 
authenticity of the original message. If a return acknowl- 
edgement is received within a given time period, the e-mail 
is deemed to be acceptable and delivered to its intended 

35 recipient within the enterprise. Mail messages from 
previously -verified addresses need not be rechecked. 

According to a preferred embodiment, a list of approved 
addresses is maintained at the e-mail server for each user, 
preferably without requiring the user's interaction. The 

40 address of any outbound e-mail sent from an e-mail client is 
automatically added to the user's approved address list. An 
inbound e-mail having a sending address that is seen for the 
first time is delivered to a holding queue instead of being 
delivered to the intended recipient. The server responds to 

45 the inbound e-mail by issuing an e-mail back to the unknown 
sending address, requesting a return acknowledgement. If 
the acknowledgement is received within a given time period, 
the e-mail is released from the holding queue and delivered 
to the intended recipient If, however, an acknowledgement 

50 is not received within the given time period, it is flushed 
from the holding queue. Using this method, spam e-mail 
accumulates in the user's holding queue instead of being 
delivered to the user's inbox because spamming is typically 
accomplished by automated routines that cannot or do not 

55 respond to the e-mail's server's request for acknowledge- 
ment. 

In a representative embodiment, a method of restricting 
unsolicited e-mail is responsive to receipt of an e-mail for 
determining whether a sending address associated with the 

60 e-mail is on a given list of approved addresses. If not, an 
e-mail is issued to the sending address requesting a return 
acknowledgement. The e-mail is then directed to a holding 
queue pending receipt of the return acknowledgement. The 
e-mail is deleted from the holding queue if the return 

65 acknowledgement is not received within a given time 
period, indicating that it is likely a spam message. On the 
contrary, the e-mail is released from the holding queue upon 
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receipt of the return acknowledgement within the given time user of the client to obtain known Internet services including 

period. In such case, the sending address is then added to the one-to-one messaging (e-mail), one -to-many messaging 

given list of approved addresses and is not rechecked if a (bulletin board), file transfer, and web browsing. Thus, a 

subsequent e-mail (originating from the same address) is user of client 108 outside the firewall 102 may communicate 

received at the e-mail server. 5 with onc °f tne clients 100 inside the firewall. A represen- 

rr , . , ii.- i j' tative client includes a Simple Mail Transport Protocol 

If desired once an e-mail having a particular sending e ^ ^ ^ ^ ^ ^ ^ MkmaR 

address has been approved for delivery to an intended ^ook, or the like. E-mail clients 105 cooperate with mail 

recipient and the sending address added to the approved servef m {n a manner A represenUlive mail 

address hst, any e-mail that originates from the same domain m includcs a bcal mai] delivcry t that stQrcs mcomi 

may also be added to address list. W e ^ m a ^ fiJe system m afld deUvers [{ {q an eQd 

According to a more particular aspect of the invention, an user ( e g . y vj a pop, IMAP or a command line program). In 

e-mail server includes a mail transport agent for receiving the Internet paradigm, a network path to a resource (e.g., a 

inbound e-mail intended for a given e-mail client, and an server) is identified by a so-called Uniform Resource Loca- 

anti-spamming agent associated with the mail transport ( 0r (URL). 

agent for blocking unsolicited e-mail. The anti-spamming 15 A representative mail server 120 is an IBM Domino 

agent includes code for generating a list of approved server comprising a processor 123, an operating system 124 

addresses for each e-mail client, and code responsive to and a mail server pr0 g ram 126. Mail server program is a 

receipt of an e-mail for a particular e-mail client for deter- local mail delivery agent( as previously noted. The server 

mining whether a sending address associated with the e-mail 12 q may include an Application Programming Interface 

is on the e-mail client's given list of approved address. The 12S ^ provides extensions to enable application 

anti-spamming agent also includes code responsive to a developers to extend and/or customize the core functionality 

negative determination for issuing an e-mail back to the thereof through software programs including plug-ins, 

sending address requesting a return acknowledgement, and servlets and the like. 

code for directing the e-mail to a holding queue for the A representative client is a personal computer, notebook 

e-mail client pending receipt of the return acknowledge- computerj Intemet appliance or pervasive computing device 

meDt " (e.g., a PDA or palm computer) that is x86-, Pentium- 

The foregoing has outlined some of the more pertinent PowerPC®- or RISC-based. The client includes an operating 

objects and features of the present invention. These objects system such as IBM® OS/2®, Microsoft Windows, 

and features should be construed to be merely illustrative of 3Q Microsoft Windows NT, Windows CE or PalmOS. As noted 

some of the more prominent features and applications of the above, the client includes a suite of Internet tools including 

invention. Many other beneficial results can be attained by a Web browser, such as Netscape Navigator or Microsoft 

applying the disclosed invention in a different manner or Internet Explorer, that has a Java Virtual Machine (JVM) 

modifying the invention as will be described. Accordingly, an d support for application plug -ins or helper applications, 

other objects and a fuller understanding of the invention may 35 The client also includes an e-mail client, such as Lotus 

be had by referring to the following Detailed Description of Notes, Microsoft Outlook, or the like, to manage e-mail 

the Preferred Embodiment. communications. 

DD1CC nccrDiDTrnw nu ttjc t^d awimpc fig - 2 is a block digram °f inventive e-mail server 

BRIEF DESCRIPTION OF THE DRAWINGS 20Q Qf ^ ^^n. E . mafl server 200 or 

For a more complete understanding of the present inven- 40 has associated therewith a mail transport agent 202 that 

tion and the advantages thereof, reference should be made to stores an inbound e-mail 203 on a local file system 204 and 

the following Detailed Description taken in connection with delivers it to an end user's e-mail client application 206. An 

the accompanying drawings in which: agent 202 typically provides the basic functionality of 

FIG. 1 is a representative SMTP-based client-server sys- h Z& n & " aQ c ' mail message and copying that message to 

tern in which the present invention is implemented; 45 a client machine's mail spool 208. According to the present 

„^ j» . i , 1 j ■ -i . invention, the e-mail server includes an anti-spamming 

FIG. 2 is a block diagram on an e-mail server that **vmr * • *■ j i- f. n v * j % 

v. r lt .* agent 210 lor restricting delivery ot bulk, unsolicited e-mail 

incorporates the functionality of the present invention; °„ „ AUU , ™^ - , 4 

v J * or spam. Although FIG. 2 illustrates the anti-spamming 

FIG. 3 is a flowchart illustrating an embodiment of the agent 2 10 as being separate from the mail transport agent, 

present invention; and 50 tnis ^ not a re q U i re ment of the invention. The anti- 

FIG. 4 is a representative administrative dialog for use in spamming agent may comprise a layer of the mail transport 

enabling an administrator to establish criteria for managing agent or be otherwise integrated therewith, 

unsolicited e-mails according to the present invention. xhe anti-spamming agent 210 comprises a set of routines 

nrTAn cn nncnDTEm/w ra: tuc and strictures. The agent 210 includes a set of lists 

^?™fSSSS?M?5^ 55 212fl - rt > each comprising addresses that have been 

PREFERRED EMBODIMENT "approved" for a particular e-mail client. Thus, for purposes 

By way of background, a known Internet client-server of illustration, each e-mail client has an associated list of 

system is implemented is and illustrated in FIG. 1. In this approved addresses. An address is said to be "approved" if 

system, a set of client machines lOOa-100/t are connected either of two (2) conditions are met: (a) it represents the 

behind a network firewall 102 within an enterprise environ- 60 address of an outbound email, i.e. the address of the recipi- 

ment. Each client machine has the capability of connecting ent of an e-mail generated by the user of the e-mail client, 

to a set of web servers 104a-104n over network 106 in a or (b) it represents a sending address which, although 

known manner. Network 106 typically includes other serv- originally unrecognized, has been verified through a return 

ers for control of domain name resolution, routing and other acknowledgement according to the present invention. In 

control functions. The network 106 is the Internet, an 65 particular, when an inbound e-mail is received at the e-mail 

Internet, or any other known network. To this end, each server from a sending address that has not been seen before, 

client typically includes a suite of programs that enable a it is classified (by default) as "spam" e-mail. As such, the 
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e-mail is placed in a holding queue 214 associated with the 
e-mail queue until is can be verified as legitimate (as 
opposed to spam). Preferably, each e-mail client also has its 
own associated holding queue 214, although one of ordinary 
skill will appreciate that the lists 2\2a-n and holding queues 5 
214a-« may comprise shared memory. 

To verify the authenticity of an unrecognized sending 
address, the agent includes a number of code sets. Each code 
set comprises one or more computer instructions. Code set 
216 is responsive to receipt of an e-mail (for a given 10 
recipient) for determining whether the sending address of 
the e-mail is on the recipient's given list of approved 
addresses. Code set 218 is responsive to a negative deter- 
mination for issuing an e-mail 215 to the sending address 
requesting a return acknowledgement. The e-mail 215 may 15 
(but need not) include an authorization code 217 that must 
be included in any return acknowledgement for the return to 
be considered authentic. Code 220 directs the e-mail to the 
e-mail client's associated holding queue 214 pending receipt 
of the return acknowledgement. Code 222 releases the 20 
e-mail to the intended recipient if a return acknowledgement 
is received with a given time period, which may be user- 
selected. Code 224 flushes the e-mail from the holding 
queue 214 if a return acknowledgement is not received 
within the given time period, which reflects that the e-mail ^ 
is more than likely spam. Finally, code 226 adds the sending 
address to the list of approved addresses for the e-mail client 
once the sending address has been verified. Of course, one 
or more of the functions provided by the code sets may be 
integrated into a single program, process or application. A 30 
particularly useful implementation of the code sets is a Java 
servlet. An instance of the servlet may be spawned for 
handling e-mail directed to a particular e-mail client 206. 

In a preferred embodiment, once an unrecognized sending 
address has been added to the list of approved addresses for 35 
a given e-mail client, the address is added to each of the 
other lists of approved addresses (for the other e-mail 
clients). In addition, if desired, all of the other lists of 
addresses can be updated to reflect that any sending address 
that originates from the same domain will also be accepted 40 
without further verification. All of these options, preferably, 
are configurable, as will be seen. 

Thus, according to the invention, a method of screening 
e-mail is provided in which incoming e-mail addresses are 
compared to an approved list and addresses not on the list 45 
are forwarded a reply, i.e. a request for acknowledgement. A 
favorable response to the forwarded reply determines 
whether or not the original e-mail is then delivered to the 
intended recipient. By default, all unrecognized inbound 
messages preferably are considered spam unless proven 50 
otherwise. The present invention effectively filters junk 
e-mail in an enterprise computing environment because 
users tend to send and receive e-mail from the same people 
or organizations. 

FIG. 3 is a flowchart of a preferred method for blocking 55 
electronic mail according to the present invention. The 
routine begins at step 300 with the system administrator or 
other user establishing a list of approved addresses for each 
e-mail client. An individual list may be empty when initial- 
ized. As described above, these lists may be a composite list. 60 
The following describes the function for a particular e-mail 
client, although one of ordinary skill will appreciate that the 
same functionality is provided concurrently for all open 
e-mail clients. At step 302, the anti-spamming agent (or an 
instance thereof) is started for the e-mail client. Typically, 65 
step 302 occurs when the e-mail client itself is launched, 
although this is not a requirement. At step 304, the agent 



tests to determine whether any outbound mail has been 
generated. If not, the routine cycles. If, however, an out- 
bound mail is generated from the e-mail client, the routine 
branches to step 306 and saves the recipient's address in the 
list of approved addresses. This operation is used because, 
typically, an address identified by the user will not be a spam 
address if the address is later seen by the agent This step, 
however, is optional, as certain outbound e-mail may not be 
directed to known or approved users. 

The routine continues at step 308 to test whether an 
inbound message for the e-mail client has been received at 
the e-mail server. Steps 304 and 308, of course, may occur 
in any order or concurrently. If the outcome of the test at step 
308 is negative, the routine cycles. Upon a positive outcome, 
however, a test is performed at step 310 to determine 
whether a sending address of an inbound e-mail is on the list 
of approved addresses for the e-mail client. If the outcome 
of the test at step 310 is positive, the routine branches to step 
312 and forwards the e-mail to the e-mail client's mail spool. 
If, however, the outcome of the test at step 310 is negative, 
which indicates that the sending or originating address of the 
inbound e-mail is not recognized on the list of approved 
addresses, the routine deems the e-mail to be unsolicited. 
Thus, the routine continues at step 314 to place the unso- 
licited e-mail in the holding queue associated with e-mail 
client. 

At step 316, the routine generates and issues to the 
sending address a new e-mail requesting a return acknowl- 
edgement. Steps 314 and 316, of course, may take place 
concurrently or in any order. The new e-mail that is issued 
from the agent may include an authorization code that must 
be included in the return acknowledgement before the 
original e-mail is accepted (i.e. released from the holding" 
queue) and delivered to the intended recipient. The use of an 
authorization code, however, is not required. By issuing an 
e-mail to the sending address of the unsolicited e-mail, the 
agent tests to determine whether the originator of this e-mail 
message will or can validate itself to the e-mail server. In this 
way, unsolicited e-mail can be effectively screened and 
blocked before it is delivered to the e-mail client. To this 
end, the routine continues at step 318 to test whether or not 
a return acknowledgement has been received within a given 
time period. The time limit may be set by default or by a 
system administrator or other user. If the outcome of the test 
is negative, the routine branches to step 320 and deletes the 
e-mail from the holding queue. In this case, the e-mail is not 
forwarded to the e-mail client because the agent has deter- 
mined that the default spam status has not been changed 
within the given time period. If, however, the outcome of the 
test at step 318 is positive, which indicates that a return 
acknowledgement (possibly including the authorization 
code) has been received, the routine continues at step 322 to 
release the e-mail from the holding queue. At step 324, the 
e-mail is forwarded to the e-mail client's mail spool for 
delivery to the user's inbox. At step 326, the sending 
address, which has now been verified as acceptable, is added 
the user's list of approved addresses. As described above, 
this address may also be added to the lists of approved 
addresses for the other e-mail clients in the enterprise if 
desired. This completes the processing. 

One of ordinary skill will recognize that the present 
invention provides many advantages over the prior art. The 
technique is simple to implement and manage, and there is 
no requirement for the end user to interact with the e-mail 
server or to otherwise be involved with the filtering process. 
The system administrator or other system user need only 
establish the list of approved addresses and then, if desired, 
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set the time limit during which the agent will wail for a mail in association with a local delivery agent application, 
return acknowledgement before deleting a suspect e-mail The present invention may be implemented as a replacement 
from a user's holding queue. for or as a supplement to the local delivery agent in such 

Most spam comes from forged e-mail addresses, making environments and thus does not require replacement of the 

return contact impossible. As a result, the inventive method s existing e-mail server. 

ensures that e-mails originating from such addresses do not In ^ 3^^,^ embodiment as described, the inventive 

get added to any approved list. anti-spamming agent is implemented as a Java servlet or 

FIG. 4 illustrates a representative dialog that may be used application; alternatively, the agent may be implemented as 

by a system administrator or other user to set various control ^ applet> nativc codCj or code implcmcme d within an 

options for the anti-spamming agent. This dialog is optional, 10 ex j stmg application (e.g., the mail transport agent). A further 

however, as default settings for the agent may be used as variation ^ t0 incorporate the inventive functionality in the 

well. A representative default setting is that any e-mail sent e . mail client itself ( or m a program associated therewith. In 

to a holding queue is saved for a period of one day; after that particular , it may be desirable to allow interaction with the 

time period, the e-mail is automatically flushed from the user of the e . mail clie[U under certain circumstanC es. Thus, 

queue if a return acknowledgement has not been received (or 15 for example( it may be desired to includc a user interface, a 

if the e-mail has not been released due to some other reason, pop . up dia]og) ^ provides an message to the user that he 

e.g., another e-mail client has approved the sending address Qr ^ has received ^ e . mail from an address that he or she 

and the system is defaulted to release all e-mail having a has not previously a p pr0 ved. The user can then be asked to 

sending address approved by any e-mail client). The dialog read ^ note and provide ^ indication that the material 

400 includes a listbox 402 identifying each of the e-mail 20 lherein ^ acC eptable, in which case the sending address 

clients. Using a fill-in box 404, the administrator can iden- might then be added t0 ^ approved address list> 

tify a time period during which a given e-maU will remain More all preferably each of me proce sses 

in a e-mail client s holding queue. A radio button 406 is , ,°, a ,l * * *u 

, , . r . *? r -i . . i_ . described above is a set of instructions or code that together 

checked if the sending address of an e-m ail that has been . . ~_. . t . 

. , f 6 , ... j j j * * , u 1*4 r comprise a computer program. This program is executable m 

released from a given holding queue is added to the list of ?< r r . r . f. 0 , ~, . r 

, 6 „ . -i r . u » • a processor running a given operating system. The set of 

approved addresses for each e-mail client. If this button is ■ . / j\ i_ Jf . 

, l 1 j 1 iL j jj i- . * .u 1 mstnicuons (program code) may be executed from a random 

not checked, only the approved address list for the e-mail * I 11*1 -ju.u 

.. . ' , \ V it Ano . . , . , access memory of a computer. Until required by the 

cheiit is updated. Arad.o button 408 ischecked .f the system ^ ^ flf iQStruc £ ons be sto w red fa J othef 

administrator desires to accept any e-mail from a sending ^ m for j ^ a har(J ^ dfi Qr m 

address ong.nadng from the same domain as an approved 30 a removable memory such ^ an optical disk (for eventua , 

address. Aradio button 410 is checked if the system admin- use . CD ROM) ' or fl ^ (f ^ ^ a 

istrator desires to move the unsolicited e-mail to a lower ^ driye) ^ down ^ aded ^ lhe Ioterne , Qr olher 

dehvery priority as opposed to deleting the e-mail from a com V uter network 

given holding queue. Thus, for example, if the administrator , v ' . . .... ... 

sets the option, he or she may fill-in box 412 to identify the 35 In add, T • alt ? 0Ugh 1 U f vanouS me , thods dcScnbcd "* 
frequency of delivery of this lower priority mail. Typically, conveniently imp emented m a general purpose computer 
however, button 410 is unchecked so that the spam can be selechvely acUvated or reconfigured by software one of 

deleted, not merely delayed. ° rd ?7 skl » ID ,he . art * ould also reco 8" lze that m * 

^ i • i M1 \ T7t/~* At -i methods may be earned out in hardware, in firmware, or in 

The dialog illustrated in FIG. 4 of course, is merely mofe tus constructed t0 perform me 

representative. Any convenient graphical controls may be *o . J melnod 

used to facilitate the user configuration desired by the 1, ... u ,■ .„ . . . j, 

system administrator. In addition, one of ordinary skill in the Pnrtte '. 45 uscd hcrcln - a cl,ent should be , 
art will recognize that the dialog may be used to define the J* 0 *™* 1 * me " aDV or c ° m P° aeDt thereof 

nature of the response that is required of the person/machine directly or indirecdy connected or correctable in any known 

, iU j- , , a * j i * ^ ;i or later-developed manner to a computer network, such as 

at the sending address. As noted above, the e-mail may 45 . il A ti „ : r . , , . . 

include an acknowledgement code that has to be entered lhe In,CTnet " ™ term ^ should ( ako , b f f bw ^ 
with the return acknowledgement for the reply to be accept- c ° nstnled t0 mean a "nipiiter computer platform, an 

able. If desired, the system administrator may use the dialog a 1 d J unc ! £ a com P^ r . or „ P' atf ?™' ° r V* com P on f nt 

, t ac- ^ „ „u„„\r\J~ thereof. Of course, a client should be broadly construed to 

screen to create or define more dimcult tasks (e.g., checking ' ( , ./ „. , 

a box, drawing a line, etc.) that will have to be performed 50 mean ° D u e req ^ °i g ^f ' S *™ * 

before the return acknowledgement is accepted and the cntlt y wtuch downloads the file. 

original sending address added to the approved address list. Havin g thus described our invention, what we claim as 

The goal, of course, is to issue an e-mail that requires a new and desire t0 secure b ? letters P atent 15 ^ forth in the 
human response and/or to make it very difficult for an following claims, 

automated spam machine to respond correctly. In addition, 55 What ^ claimed is: 

the system administrator might use the dialog to include a L An e-mail system connectable to a computer network, 

warning in the e-mail to the effect that unless a return comprising: 
acknowledgement is received within a given time period a ma il server; 

(e.g., as set by fill-in box 404), the original e-mail will not a plurality of e-mail clients connectable to the mail server, 

be delivered. The dialog may also include appropriate fields 60 eacn of ^ plurality of e-mail clients having a list of 
and controls to allow the administrator or other user to add approved addresses; 

addresses to a user's approved address list. a mail transport agent for receiving inbound e-mail from 

As is well-known, many e-mail servers support the con- the computer network and forwarding the inbound 

cept of a local delivery agent that analyzes inbound mail and e-mail to given e-mail clients, and for forwarding 

determines how such mail is to be delivered to the local 65 outbound e-mail from the e-mail clients to the corn- 
use r*s mail spool. Thus, for example, a conventional mail puter network; 
server is a Unix -based computer running open source Send- an anti-spamming agent, comprising: 
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code responsive to receipt of an e-mail directed to one 
of the plurality of e-mail clients from the computer 
network for determining whether a sending address 
of the e-mail is on the list of approved addresses for 
the e-mail client for which the e-mail is directed; 5 
code responsive to a determination that the e-mail is not 
on the list of approved addresses for issuing an 
e-mail to the sending address requesting a return 
acknowledgement; 
code for directing the e-mail to a hold queue pending 10 

receipt of the return acknowledgement; 
code for releasing the e-mail from the hold queue upon 

receipt of the return acknowledgement; and 
code for adding the sending address of the e-mail to the 
lists of approved addresses for others of the plurality is 
of e-mail clients. 
2. In an e-mail system comprising a mail server and a 
plurality of e-mail clients connectable to the mail server, 
each of the plurality of e-mail clients having a list of 
approved addresses, a method comprising the steps of: 20 
receiving an e-mail directed to one of the plurality of 
e-mail clients; 

determining whether a sending address of the e-mail is on 
the list of approved addresses for the e-mail client for 
which the e-mail is directed; 

responsive to a determination that the e-mail is not on the 
list of approved addresses, issuing an e-mail to the 
sending address requesting a return acknowledgement; 
and 
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after receipt of the return acknowledgment, adding the 
sending address of the e-mail to the list of approved 
addresses for the e-mail client and to the lists of 
approved addresses for others of the plurality of e-mail 
clients. 

3. A computer program product in a computer useable 
medium, and operable with an e-mail system comprising a 
mail server and a plurality of e-mail clients connectable to 
the mail server, each of the plurality of e-mail clients having 
a list of approved addresses, the computer program product 
comprising: 

means for receiving an e-mail directed to one of the 
plurality of e-mail clients; 

means for determining whether a sending address of the 
e-mail is on the list of approved addresses for the e-mail 
client for which the e-mail is directed; 

means, responsive to a determination that the e-mail is not 
on the list of approved addresses, for issuing an e-mail 
to the sending address requesting a return acknowl- 
edgement; and 

means for adding the sending address of the e-mail to the 
list of approved addresses for the e-mail client and to 
the lists of approved addresses for others of the plu- 
rality of e-mail clients after receipt of the return 
acknowledgment. 



03/10/2004, EAST Version: 1.4.1 



